An application platform may implement metadata models to support different business solutions. Metadata models may include generic models of a business object, a floorplan (i.e., a user interface layout), user interface text, a process component, and a message type, among others. A business object, for example, is a software model representing real-world items used during the transaction of business. An instance of a business object metadata model may comprise a SalesOrder object model or an Organization object model. Instances of these object models, in turn, represent specific data (e.g., SalesOrder 4711, ACME corporation).
An instance of a business object metadata model (e.g., a SalesOrder object model or, more generically, a business object object model) may specify business logic and/or data having any suitable structure. The structure may be determined based on the requirements of a business scenario in which the instance is to be deployed. A business application for a particular business scenario may require many business object object models, where the structure of each has been determined based on the requirements of the particular business scenario.
The data stored by an application platform is typically accessed according to one of two primary modalities. The first, which may be referred to as an operational modality, involves accessing and modifying the data during the day-to-day course of business. The operational modality may include, for example, reviewing and updating inventory, inputting sales figures, issuing paychecks based on salary and attendance data, etc.
An analytical modality, on the other hand, generally consists of strategic analysis of business data. Activities of the analytical modality may include comparison of profit margins by location, product and/or year, sales by brand, etc. Of course some activities may be arguably classified as belonging to either the analytical modality or the operational modality.
A software solution may provide data queries, user interfaces and reports for presenting the data underlying business object object models. These queries, interfaces and reports are developed by the solution provider based on knowledge of the structure and semantics of the business object object models. Customers and partners may customize or develop similar queries, interfaces and reports, based also on the business object object models.
A customer deploying such a software solution might use pre-defined user interfaces to interact with the business objects. Often, however, a customer will want to customize these user interfaces based on the business needs of the customer. For example, a customer may wish to change a user interface associated with a SALES_ORDER business object by adding a “Sub-Product Identifier” field next to an existing “Product Identifier” field.
In order to maintain internal consistency of the software solution, this change requires modification of the user interface and of the SALES_ORDER business object. In particular, the SALES_ORDER business object is modified to include the extension field “Sub-Product Identifier”. Commonly-assigned co-pending U.S. patent application Ser. No. 12/339,328, entitled “UI-Driven Binding Of Extension Fields To Business Objects”, describes systems for facilitating the above-described change. The contents of U.S. patent application Ser. No. 12/339,328 are incorporated herein by reference for all purposes.
Although extension fields may be available for consumption by user interfaces, print forms, and service interfaces within the software solution, conventional systems do not facilitate usage of extension fields within analytical reports. Improved systems for utilizing extension fields within analytical reports are desired.